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SAMeDL:  What  is  it?  Why  is  it  important? 

Who  can  help? 


Background 

As  the  Ada  programming  language  becomes 
more  widely  used  for  information  systems  devel¬ 
opment,  a  viable  interface  between  Ada  and  off- 
the-shelf  database  management  systems  (DBMS) 
is  a  critical  requirement  for  success.  To  ensure 
longevity  of  the  applications  software,  as  well  as 
to  enhance  maintenance  and  reliability,  most  Ada 
information  systems  developers  prefer  to  use 
established  standards  to  support  their  development 
activities.  For  information  systems,  this  prefer¬ 
ence  for  standards  means  using  Structured  Query 
Language  (SQL)  as  a  means  of  accessing  commer¬ 
cial  DBMS  products. 

SQL  and  Ada  are  both  ANSI  (American 
National  Standards  Institute)  and  DoD  (Depart¬ 
ment  of  Defense)  standards.  Both  standards  are 
also  required  for  the  development  of  DoD  infor¬ 
mation  systems,  and  for  other  applications  which 
require  the  use  of  a  DBMS  (i.e.,  command  and 
control  systems).  Unfortunately,  the  task  of 
interfacing  Ada  and  SQL  is  complex  and  non¬ 
trivial  in  scope.  The  underlying  computational 
models  for  the  two  languages  are  very  different, 
and  they  were  not  explicitly  designed  to  work  with 
each  other. 

Although  SQL  is  an  ANSI  standard,  most 
DBMS  implementations  of  the  standard  offer 
“extensions”  which  provide  more  power  to  DBMS 
users.  These  non-standard  features  provide 
pragmatic  real-world  capabilities  to  users,  while  at 
the  same  time  significantly  complicating  the  task 
of  information  systems  developers.  If  a  developer 
makes  extensive  use  of  non-standard  SQL  fea¬ 
tures,  the  portability  of  the  application  can  be 
severely  degraded. 


In  1989,  ANSI  promulgated  two  Ada/SQL 
bindings  that  specify  standard  approaches  for 
binding  Ada  applications  to  SQL  databases. 
Unfortunately,  the  ANSI  bindings  do  not  support 
user-defined  types  and  the  safe  handling  of  “null” 
values  in  a  database.  Furthermore,  the  ANSI 
standards  do  not  enforce  the  extensive  compile¬ 
time  checks  that  Ada  developers  have  come  to  rely 
on,  requiring  instead  the  use  of  expensive  run-time 
error  traps. 

impact  on  Developers 

The  benefits  normally  associated  with  the 
use  of  Ada  (i.e.,  maintainability,  reusability, 
portability,  etc.)  are  primarily  dependent  on  the 
application  of  sound  software  engineering  prin¬ 
ciples.  Use  of  proven  software  engineering 
concepts,  such  as  information  hiding,  abstraction, 
modularity,  etc.,  can  pay  off  in  the  form  of  lower 
maintenance  costs,  and  higher  levels  of  portability 
and  reuse.  Ada  readily  supports  the  application  of 
sound  software  engineering  techniques  and 
methods,  which  is  the  dominant  sU'ength  of  the 
language. 

By  comparison,  SQL  was  developed  to 
support  the  definition,  manipulation,  and  control 
of  data  in  a  relational  database.  As  a  special- 
puipose  language  for  database  operations,  SQL 
was  not  designed  to  be  used  in  conjunction  with  a 
powerful  programming  language  such  as  Ada. 
Unlike  Ada,  SQL  does  not  provide  support  for 
applying  the  principles  of  software  engineering. 
The  requirement  for  using  SQL  in  combination 
with  Ada  applications  code  can  cause  major 
problems  in  accuracy,  performance,  portability, 
and  reuse. 


Embedded  Versus  Module  SQL 
Approach 

Historically,  vendors  of  SQL  products 
almost  always  provide  access  to  a  DBMS  by 
allowing  users  to  “embed”  SQL  statements  in  their 
application  software.  In  the  “embedded”  ap¬ 
proach,  the  developer  places  DBMS  manipulation 
(SQL)  statements  at  the  appropriate  points  in  the 
application  code,  intermixed  with  the  code  written 
in  the  application’s  programming  language.  A 
pre-processor  then  takes  out  the  SQL  instructions 
and  replaces  them  with  the  DBMS-specific  calls. 

A  “module”  approach,  by  comparison, 
encapsulates  all  of  the  SQL  statements  in  separate 
modules.  The  application  program  then  makes 
calls  to  the  SQL  modules,  rather  than  having  the 
SQL  statements  intermixed  with  applications  code 
throughout  the  software  system.  For  the  ANSI 
Ada/SQL  bindings,  both  an  embedded  and  a 
procedural  or  module  form  are  included.  In  the 
procedural  form,  access  to  the  DBMS  is  through 
Ada  procedure  calls  to  the  SQL  procedures 
contained  in  the  SQL  module. 

The  embedded  SQL  approach  results  in 
applications  code  that  contains  SQL  statements 
throughout  the  entire  program.  Given  the  propen¬ 
sity  of  DBMS  vendors  to  provide  “extended”  SQL 
features  in  their  products,  the  result  of  an  embed¬ 
ded  SQL  approach  is  an  application  that  is  inextri¬ 
cably  tied  to  a  particular  DBMS.  An  infonnation 
system  developer  sacrifices  virtually  all  portability 
and  future  reuse  when  using  an  embedded  SQL 
approach. 

In  the  module  approach,  the  ability  to 
encapsulate  the  SQL  statements  in  a  single  module 
provides  an  opportunity  for  increased  portability 
and  independence  from  product-specific  features. 
The  module  approach  is  more  in  line  with  the 
application  of  sound  software  engineering  prin¬ 
ciples,  and  it  allows  the  information  systems 
developer  to  more  thoroughly  exploit  the  power 
and  features  of  the  Ada  language. 


Although  the  ANSI  Ada/SQL  bindings 
include  both  an  embedded  standard  and  a  module 
standard,  vendors  are  not  required  to  provide  both 
fonns  of  the  bindings  to  be  ANSI  complianL  Most 
DBMS  vendors  offer  an  embedded  Ada/SQL 
capability,  and  the  embedded  form  is  expected  to 
be  the  predominant  product  offering  in  the  future. 
Even  though  the  module  form  of  the  ANSI  binding 
helps  in  developing  more  portable  applications,  it 
does  not  support  user-defined  types  and  the  safe 
handling  of  “null"  values  in  a  DBMS. 

The  Importance  of  Handling 
“Null”  Values 

The  safe  handling  of  “null”  values  in  a 
database  is  of  special  concern  to  information 
systems  developers.  Null  values  are  peculiar  to 
relational  database  processing,  as  they  indicate 
missing  or  unknown  information.  The  Ada 
language  itself  does  not  have  a  means  of  identify¬ 
ing  or  handling  unknown  data.  By  comparison, 
SQL  provides  a  set  of  operators  which  handle 
incomplete  information.  These  operators  are  used 
by  SQL  for  its  own  processing,  but  the  operators 
are  not  “exported”  to  the  application  programming 
language. 

In  SQL.  data  objects  in  an  application 
program  have  two  parts:  a  variable  which  holds 
the  value  of  the  item;  and  an  “indicator”  which 
indicates  whether  or  not  the  value  is  null.  In  other 
words,  the  "indicator"  shows  whether  the  value  is 
meaningful  for  the  operation  being  performed. 
Improper  handling  of  these  indicators  can  lead  to 
subtle  software  errors,  where  seemingly  valid 
results  are  wrong. 

A  good  real  worid  example  of  the  impact  of 
a  null  value  would  be  the  instance  in  which  a 
database  concerning  personnel  information  is 
polled  to  calculate  the  average  age  of  employees. 
Since  an  employee  is  not  required  to  disclose  his/ 
her  age.  the  age  field  in  the  database  may  be 
missing,  or  “null.”  In  this  example,  if  the  null 
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value  is  included  in  the  calculation  (no  value  for 
the  age,  but  the  employee  is  included  in  the  divisor 
for  the  average),  the  result  is  not  accurate. 

SAMeDL — Its  origins,  implemen¬ 
tation,  and  benefits 

The  challenges  pertaining  to  the  use  of  Ada 
and  SQL  in  a  well-engineered  information  system 
led  to  the  formation  of  the  SQL  Ada  Module 
Extension  Design  Committee  (SAME-DC)  at  the 
Software  Engineering  Institute  (SEI).  The  com¬ 
mittee  developed  the  SQL  Ada  Module  Extension 
(SAME)  methodology  to  support  and  extend  the 
modular  approach  to  using  Ada  and  SQL  in 
database  applications.  The  language  which  is  used 
to  implement  SAME  is  the  SQL  Ada  Module 
Description  Language,  or  SAMeDL. 

Using  the  SAME  methodology  requires  that 
SQL  statements  be  separated  from  the  Ada  appli¬ 
cation  code,  and  encapsulated  in  separate  modules. 
The  SQL  statements  are  not  embedded  in  the  Ada 
packages,  thus  isolating  the  Ada  application  from 
the  DBMS  design  and  implementation. 

SAMeDL  is  designed  to  facilitate  the 
construction  of  Ada  database  applications  that  use 
the  SAME  methodology.  The  SAME  method 
involves  the  use  of  an  abstract  interface,  an 
abstract  module,  a  concrete  interface,  and  a 
concrete  module. 

—  The  abstract  interface  is  a  set  of  Ada 
package  specifications  containing  the 
type  and  procedure  declarations  to  be 
used  by  the  Ada  application  program. 


—  The  concrete  interface  is  a  set  of  Ada 
specifications  that  define  the  SQL 
procedures  needed  by  the  abstract 
module. 

—  The  concrete  module  is  a  set  of  SQL 
procedures  that  implement  the  con¬ 
crete  interface. 

To  implement  the  SAME  methodology, 
SAMeDL  provides  the  language  constructs  from 
which  three  types  of  modules  are  written;  the 
definition  module;  the  schema  module;  and  the 
abstract  module.  The  three  modules  together 
comprise  a  compilation  unit  for  the  SAMeDL 
compiler.  The  definition  module  contains  the 
declarations  of  domains,  constants,  records, 
enumerations,  exceptions,  and  status  maps.  The 
schema  module  contains  the  declaration  of  tables, 
views,  and  privileges.  The  abstract  module 
contains  procedure  and  cursor  declarations. 

The  SAME  methodology  uses  Ada  features 
to  provide  the  following  services  to  Ada/SQL 
applications: 

•  Safe  treatment  of  SQL  data  that  may 
contain  null  values.  SAMeDL  pro¬ 
vides  robust  treatment  of  SQL  data 
within  application  programs  which 
effectively  prevents  use  of  null  values 
as  though  they  were  not  null.  Tho 
SAMeDL  treatment  requires  no  run¬ 
time  conversion  of  non-null  data. 


The  abstract  module  is  a  set  of  bodies 
for  the  abstract  interface.  These 
bodies  are  responsible  for  invoking 
the  routines  of  the  concrete  interface, 
and  converting  between  the  Ada  and 
the  SQL  data  and  error  representa¬ 
tions. 


Flexible  handling  of  DBMS  errors  and 
exceptional  conditions.  This  feature 
allows  application  designers  to  decide 
which  conditions  are  expected  and 
which  are  irrecoverable.  However,  it 
prevents  any  such  DBMS  conditions 
from  being  “missed”  by  the  applica¬ 
tion. 

Enforcement  of  a  strong  typing 
discipline  to  SQL  statements  and  user- 
defined  types.  This  service  provides 
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an  extended  database  description 
using  abstract,  application-oriented 
types  as  well  as  tiie  strong  typing 
discipline  for  the  SQL  statements. 

Applying  the  SAME  methodology  enhances 
the  following  attributes  of  an  Ada  information 
system: 

•  Conceptual  aaritv  It  is  good  design 
practice  to  separate  the  database 
statements  in  an  application  from  the 
application  logic.  This  allows  the 
application’s  information  needs  to  be 
captured  during  the  design. 

•  Portability  The  great  bulk  of  the  code 
of  any  database  application  lies  in  the 
application’s  logic,  as  distinct  from 
the  database  logic.  Since  SAME  Ada 
applications  contain  no  SQL  state¬ 
ments,  they  port  from  one  DBMS  to 
another  without  modification. 

•  Simplicity  Giyen  the  differences 
between  Ada  and  SQL  (i.e.,  the  syntax 
and  semantics  of  the  two  languages), 
coding  in  both  languages  simulta¬ 
neously  is  yery  confusing. 

These  attributes  haye  significant  payoffs  for 
the  deyeloper.  The  SAME  methodology,  by  yirtue 
of  its  enforced  modularity  and  encapsulation, 
supports  the  use  of  object-oriented  software 
deyelopment  for  Ada-based  information  systems. 
The  conceptual  clarity  of  the  approach  contributes 
to  the  early  detection  of  errors  in  the  deyelopment 
cycle,  which  helps  to  lower  the  cost  of  finding  and 
fixing  software  problems  during  deyelopment. 

The  modular,  encapsulated  nature  of  SAME 
also  facilitates  the  management  of  the  deyelop¬ 
ment  team,  and  aids  in  the  assignment  of  discrete 
tasks  to  staff  members  with  particular  leyels  of 
expertise.  For  example,  SQL  experts  can  focus  on 
the  statements  required  to  operate  the  DBMS 
being  used,  while  the  Ada  software  engineers  can 


concentrate  on  the  design  and  deyelopment  of  the 
Ada  application  code.  The  simplicity  of  working 
in  a  single  language  pays  off  significantly  in  the 
form  of  increased  pnoduaiyity,  higher  quality, 
fewer  errors,  more  straightforward  project  track¬ 
ing,  and  higher  team  morale. 

Real  World  Experience  with 
SAMeDL 

In  September  1991,  Statistica,  Inc.,  in 
Reston,  Virginia,  was  awarded  an  Ada  Technology 
Insertion  Program  (ATTP)  contract  to  explore  the 
merits  of  SAME  on  a  real  information  system 
application.  The  project  used  SAMeDL  to  rede¬ 
sign  the  SQL  interface  of  an  existing  application, 
in  this  case  the  U.S.  Army’s  Standard  Installation 
Diyision  Personnel  System  (SlDPERS-3). 
SIDPERS-3  was  originally  designed  using  another 
Ada/SQL  binding. 

Statistica  approached  the  project  in  two 
phases.  The  first  phase  inyoWed  the  replacement 
of  the  SIDPERS-3  SQL  binding  layer  with  a 
duplicate  layer  implemented  in  SAMeDL.  The 
Ada  application  design  and  code  remained  un¬ 
changed.  The  purpose  of  the  first  phase  was  to 
determine  the  ease  of  conyerting  an  existing  Ada/ 
SQL  application  to  SAMeDL.  In  the  second 
phase,  Statistica  redesigned  and  re-implemented 
the  SQL  binding,  to  demonstrate  the  benefits  of  an 
up-front  SAME  design  approach. 

Phase  1  Approach 

In  the  first  phase  of  the  project,  Statistica 
identified  two  Computer  Software  Units  (CSUs) 
from  the  SIDPERS-3  application  for  re-implemen¬ 
tation  using  SAMeDL.  These  CSUs,  listed  in 
Table  1,  were  selected  on  the  basis  of  the  function¬ 
ality  and  services  required  of  the  database.  To 
facilitate  the  analysis  and  measurement  of  perfor¬ 
mance.  each  CSU  in  the  application  layer  repre¬ 
sents  a  complete  thread  of  control. 
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packages.  These  packages  declare  subtypes  which 
correspond  to  each  column  in  the  database. 

The  SIDPERS-3  team  also  developed  a 
Man-Machine  Interface  (MMI)  to  handle  all  user 
interfaces,  including  reports.  Data  is  passed 
between  the  MMI  and  the  Ada  application  code  as 
string  objects.  The  Types  packages  mentioned  in 
the  previous  paragraph  also  serve  the  MMI  by 
eliminating  a  conversion  layer  between  the 
application  and  the  MMI. 

*  Sourct  Lints  of  Code 

Table  1:  CSUs  in  the  Ada  Application  Layer 
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The  original  SIDPERS-3  implemen¬ 
tation  used  a  commercial  database  product. 
XDB,  which  includes  an  SQL  module 
compiler  that  provides  the  binding  between 
the  Ada  application  code  and  the  XDB 
relational  database  product.  Using  the 
XDB  binding,  the  programmer  declares  the 
SQL  types  and  statements  required  by  the 
application  in  the  SQL  Module.  As  shown 
in  Figure  1,  the  SQL  Module  Compiler 
processes  the  SQL  Module  to  generate  Ada 
package  specifications  and  bodies. 

With  the  XDB  binding,  the  Ada 
packages  are  dependent  upon  the 
SQL_Standard,  SQL_Definitions,  and 
Dynamic_SQL  packages  supplied  by 
XDB.  At  this  point  in  the  process,  the 
SQL  interface  is  compiled  with  the  appli¬ 
cation  coded  ^d  linked  into  the  Ada 
executable. 

Figure  2  (next  page)  shows  the 
design  strategy  used  by  the  SIDPERS-3 
development  team.  Early  design  decisions 
were  predicated  on  the  use  of  XDB  data¬ 
base  product,  with  its  product-specific 
Ada/SQL  binding.  Since  neither  the 
binding  nor  the  database  product  itself 
support  strong  typing,  the  SIDPERS-3 
design  team  created  a  layer  of  Type 


Figure  2.  The  SIDPERS-3  Prototype  Design  Strategy 


To  avoid  the  bulky  processing  required  to 
test  the  “nullness”  of  data  values,  the  SIDPERS-3 
design  team  created  the  database  with  NOT  NULL 
columns.  In  the  Database  Support  Layer,  data 
retrieved  from  the  database  is  explicitly  converted 
to  SIDPERS-3  types  before  processing  by  the 
application  layer.  The  Database  Support  layer 
isolates  the  SIDPERS-3  application  code  from 
changes  that  may  occur  to  the  database. 

In  the  first  phase  of  the  SAMeDL  project, 
the  SQL  Module  files  (written  in  SQL  module 
language)  were  replaced  with  SAMeDL  modules. 
This  step  was  completed  quickly,  since  only 
certain  tables  and  columns  were  required  for  the 
selected  CSUs.  The  SAMeDL  Modules  were  then 
submitted  to  the  the  SAMeDL  compiler  for 
generation  of  the  Ada  packages.  The  generated 
Ada  packages  replaced  the  Database  Access  files 
from  the  original  SIDPERS-3  model  (refer  to 
Figure  2). 


The  next  step  in  the  first  phase  of  the  project 
was  the  modification  of  the  Database  Support 
packages.  Minor  changes  were  made  to  these 
packages,  to  remove  Commit_Work  and  Rollback 
procedures.  Since  those  procedures  are  provided 
as  standard  constructs  by  SAMeDL,  they  were 
declared  in  the  SAMeDL  abstract  modules. 
Procedures  or  functio.is  were  added  to  the  Data¬ 
base  Support  packages  to  convert  the  SAMeDL 
types  to  SIDPERS-3  data  types,  to  minimize 
changes  to  the  application  layer.  Finally,  the 
exception  handlers  were  removed  and  replaced  by 
the  SAMeDL  error  handling  routines. 

First  Phase  Results  and  Analysis 

The  cost  of  converting  to  SAMeDL  on  the 
SIDPERS-3  project  was  low.  The  ease  of  conver¬ 
sion  can  be  attributed  to  the  Module  binding 
provided  by  XDB  and  the  layering  approach  used 
to  isolate  the  database  from  the  applications  code. 
With  the  exception  of  some  error  handling,  the 
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conversion  did  not  derive  any  benefits  from 
converting  to  SAME.  The  strong  typing  was  lost 
when  the  data  moved  into  the  application  layer. 
Also,  since  the  database  was  created  with  NOT 
NULL  columns,  the  application  did  no',  take 
advantage  of  SAMeDL's  handling  of  null  fields. 

The  single  SAME-related  benefit  on  the 
SIDPERS-3  conversion  was  a  further  isolation  of 
the  application  software  from  a  change  to  another 
DBMS.  That  benefit  would  be  negated,  however, 
if  the  new  DBMS  did  not  support  the  SAME 
architecture. 

Several  issues  should  be  addressed  when 
considering  the  adoption  of  SAME  for  Ada 
database  applications.  This  is  especially  true  for 
an  application  where  the  preliminary  design  has 
already  been  completed.  Some  of  the  more 
important  issues  include  the  following: 

•  How  is  the  MMI  designed?  Can  the 
MMI  be  easily  altered  to  use 
SAMeDL  types?  The  M’vfl  developed 
for  SIDPERS-3  was  designed  to  meet 
the  specific  requirements  of 
SIDPERS-3.  The  MMI,  therefore, 
directly  controlled  the  design  of  the 
application.  The  original  SIDPERS-3 
implementation  was  designed  with 
weaker  user-defined  types  throughout 
the  application  layer  to  meet  the 
interface  requirements  of  the  MMI. 
Converting  to  SAMeDL  would 
require  major  modifications  to  the 
application  layer. 

•  What  is  the  cument  database  interface? 
Does  the  current  design  isolate  the 
database?  Does  the  application 
directly  reference  the  SQL  types? 

•  What  is  the  size  of  the  system?  The 
number  of  changes  and  level  of  effort 
for  a  SAMeDL  conversion  increase 
propx)rtionately  with  the  size  of  the 
system. 

The  “bottom  line”  result  of  the  first  phase 
effort  was  that  no  value  was  added  by  converting 


the  SIDPERS-3  SQL  interface  to  the  SAME 
architecture.  To  realize  the  extensive  benefits  of 
SAME,  the  SIDPERS-3  application  would  have  to 
be  redesigned  and  re-implemented  using 
SAMeDL — an  effort  which  was  the  impetus  for 
the  second  phase  of  the  project. 

Phase  2 — Redesign  and 
Reimplement  with  SAMeDL 

The  second  phase  of  the  SAMeDL  project 
involved  the  redesign  and  re-implemeniation  of 
the  same  SlDPERS-3  CSUs  that  were  converted  in 
the  first  phase.  Instead  of  a  simple  conversion, 
and  rather  than  starting  with  a  new  application,  the 
project  te?.n  redesigned  and  re-implemented  the 
same  CSUs  that  were  listed  in  Table  1.  This 
approach  was  taken  to  ensure  an  accurate  baseline 
for  comparisons  between  the  design  methodolo¬ 
gies,  with  both  methods  being  used  on  the  same 
functional  application. 

The  second  phase  was  implemented  using 
five  steps: 

1.  Analyze  the  data  requirements  of 
the  CSl)  to  identify  objects  or 
specific  data  groups.  For  example, 
data  identifying  a  soldier,  such  as 
social  security  number  (SSN)  and 
name,  comprise  a  Soldier  object  The 
data  identifying  a  Unit  (i.e..  Unit 
Identification  Code  (UlC)  and  name) 
are  attributes  of  the  Unit  object. 

2.  Build  SAMeDL  domains  and 
support  packages  around  each 
object.  For  each  object  a  SAMeDL 
definition  module  was  written  to 
declare  the  attribute  domain  of  the 
object.  A  corresponding  SAMeDL 
abstract  module  was  writ  en  to 
provide  all  of  the  datab'se  operations 
required  to  use  the  object. 

3.  Modify  the  database  schema  to 
represent  the  real  world.  Where 
appropriate,  the  project  team  changed 
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database  columns  to  allow  null  values. 
The  project  team  then  created  a 
SAMeDL  schema  module  to  match 
the  new  database  schema. 

4.  rnmitile  SAMeDL  modules.  For 
each  definition  module,  the  SAMeDL 
compiler  generates  an  Ada  specifica¬ 
tion  package  ea  hich  derived  types 
are  deciaieJ  for  each  domain.  Addi¬ 
tionally  the  SAMeDL  compiler 
creates  a  set  of  Ada  packages  for  each 
abstract  module.  This  set  of  Ada 
packages  is  the  abstract  interface 
defined  in  the  SAME  architecture.  In 
the  XDB  version  of  the  SAMeDL 
compiler,  a  third  set  of  packages 
(actually  generated  by  the  XDB 
module  compiler)  is  required  to 


implement  the  database  calL  in  the 
abstract  module.  This  third  set  of 
packages  becomes  the  concrete 
interface  in  the  SAME  architecti’re. 

5.  Redesign  and  modify  the  applica¬ 
tion  layer.  The  project  team  identi¬ 
fied  several  goals  in  redesigning  the 
application  layer: 

a.  Replace  the  weaker  subtypes  in  the 
Types  package  with  SAMeDL  derived 
types.  The  objective  of  this  goal  was 
to  remove  the  redundant  type  declara¬ 
tions  and  enf'i'rce  compile-time  checks 
through  derived  limited  private  types. 

b.  Hide  implementation  details  of  the 
Data  Stores  by  encapsulating  Data 
Stores  within  the  support  packages. 
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The  objective  for  this  step  was  to 
utilize  information  hiding  and  to  give 
the  design  a  more  "object-oriented” 
flavor. 

c.  Retain  strong  data  typing  up  to  the 
point  where  the  MMI  controls  the 
data.  The  objective  here  was  to 
process  the  data  using  the  operations 
defined  for  each  data  type  and  take 
advantage  of  compile  time,  rather  that 
run  time,  error  detection. 

The  resulting  SAMeDL  Redesign  Architec¬ 
ture  is  shown  in  Figure  3. 

Phase  2  Analysis 

To  take  full  advantage  of  the  many  benefits 
offered  by  the  SAME  architecture,  SAMeDL  must 
be  the  basis  for  the  design  of  an  Ada/SQL  data¬ 
base  application.  Once  the  database  design  has 
become  stable,  the  SAMeDL  modules  can  be 
designed  and  written.  Database  stability  is  the  key 
to  success  in  implementing  SAMeDL — since  the 
application  layer  is  built  on  top  of  the  SAMeDL 
data  types,  any  change  in  the  database  schema 
resulting  in  a  change  to  the  SAMeDL  types 
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Figure  4;  The  SAMeDL  Cortversion  Layers 


requires  modifications  to.  and  recompilation  ot, 
the  application  layer. 

To  maintain  strong  typing,  either  a  conver¬ 
sion  layer  must  be  inserted  between  the  applica¬ 
tion  and  the  MMI  (see  Figure  4),  or  the  MMI  must 
be  designed  to  reference  the  SAMeDL  types 
directly. 

Conclusions 

SAMeDL  is  another  programming  language 
that  can  be  as  complex  to  use  as  is  Ada.  It  is  a 
hybrid  of  both  Ada  and  SQL,  offering  the  best 
features  of  Ada,  and  allowing  the  user  to  specify 
database  services  in  SQL-like  statements.  The 
user  must  therefore  be  proficient  in  both  Ada  and 
SQL,  while  learning  a  third  programming  medium. 
Program  managers  must  consider  the  impact  of 
training  and  learning  curve  delays  on  SAMeDL 
application  develop  nent  schedules. 

The  SAME  methodology  provides  a  mecha¬ 
nism  for  enforcing  good  software  engineering 
during  the  development  of  new  information 
systems.  However,  the  gains  in  quality  are  not 
free.  Database  stability,  user  interface  design,  and 
user  training  are  factors  that  must  be  considered  by 
any  project  developing  a  new  application  with 
SAMeDL. 

SAMeDL  Tools 

As  a  part  of  the  SAMeDL  project  on  the 
SIDPERS-3  application,  a  SAMeDL  toolset  was 
developed  for  four  commercial  database  manage¬ 
ment  products  (Informix.  Oracle,  Sybase,  and 
XDB).  Intermetrics.  Inc.,  developed  the  SAMeDL 
tools  that  were  used  during  the  project. 

The  toolset  includes  a  SAMeDL  compiler 
and  Module  Manager.  The  Module  Manager  is  a 
library  manager  that  maintains  source  code  control 
and  performs  consistency  checks  on  SAMeDL 
source  code  and  its  corresponding  Ada/SQL 
interface. 
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